Conventional digital computing circuits (e.g. corresponding microcontroller or microprocessor systems arranged on a microchip) comprise one or a plurality of (central) control or processing units (Central Processing Units (CPUs), or CPU “cores”).
The CPU or the CPUs are—via a system bus (and possibly one or a plurality of further bus systems)—connected with one or a plurality of (external or internal) memories, e.g. a program and a data memory (“program memory” and “data memory”).
The “program memory” comprises in particular the sequence of the commands to be processed by the CPU core(s), i.e. the program (and possibly additionally corresponding data constants to be used by the CPU core(s)).
The program memory may, for instance, be an EPROM (Erasable PROM) or an EEPROM (Electrically Erasable PROM), in particular a flash EEPROM device.
Thus, it can be achieved that the program remains stored on the corresponding memory even if the current supply is interrupted.
For programs that are to be changed frequently, RAMs (RAM=Random Access Memory or read-write memory), in particular DRAMs, may, for instance, also be—alternatively—used as program memories that are adapted to be loaded from an external mass storage.
In the above-mentioned “data memory”, the variables which are possibly to be modified in particular by the CPU core(s) during the execution of the program may be stored.
The data memory may, for instance, be composed of one or a plurality of RAM devices, in particular e.g. an appropriate DRAM device (DRAM=Dynamic Random Access Memory) or SRAM device (SRAM=Static Random Access Memory).
A software program (or several such programs) to be processed by the CPU core may be subdivided into a plurality of appropriate software tasks (threads).
This has, for instance, the advantage that—in particular e.g. in the case of so-called multithreaded (MT) microcontroller or microprocessor systems—a plurality of different threads each may be loaded competitively into one and the same CPU core and be processed there.
By means of multithreaded (MT) microcontroller or microprocessor systems, particular resources—in particular e.g. the execution pipeline (processing pipeline)—can be utilized more efficiently.
Clock times in which there is a delay in a particular thread loaded into the CPU core for certain reasons, may be used for processing a further thread also loaded into the CPU core.
For storing the status or “context”, respectively, of—possibly a plurality of—threads loaded into the CPU core, elements such as program counter (PC), execution status register, register file, etc., etc. are possibly present several times over in a multithreaded (MT) microcontroller or microprocessor system.
Thus, a plurality of different threads can be kept simultaneously in one and the same CPU core, and appropriate switching between the threads can be performed.
Usually, only a small portion of the respective threads to be executed is kept simultaneously in the CPU core; the remaining threads to be executed are latched outside the CPU core until they are loaded into the CPU core.
The scheduling of the threads thus takes place in two steps: In a first scheduling step it is decided when which threads (that are latched outside the CPU core and) that are scheduled for execution are loaded into the CPU core and are assigned to a corresponding “context” (“off-core thread scheduling” or “thread scheduling”). In a second subordinated step it is decided when which of the threads that have been loaded into the CPU core and have been assigned to a context has to be executed (“on-core thread scheduling” or “context scheduling”).
In the case of conventional multithreaded (MT) microcontroller or microprocessor systems, the “context scheduling” is usually controlled by hardware and the “thread scheduling” by software.
For both scheduling steps, respectively different scheduling strategies may be used. Generally speaking, the object of the “context scheduling” (and possibly also of the “thread scheduling”) is the optimization of a corresponding cost function, in particular e.g. the achieving of a throughput that is as high as possible, the so-called tolerance of corresponding latencies, or a use of the processor resources that is as optimal as possible, respectively, etc., etc., and the object of the “thread scheduling” is e.g. the determination of a conflict-free succession of program flows, or the prioritization of program flows by means of real time requirements, etc.
Conventional context scheduling methods or context scheduling strategies, respectively, are based on (“quasi static) priorities (that are definitely allocated and are assigned to the individual threads to be executed).
A consequence of this is that, as a rule—in the meaning of the above-mentioned and/or corresponding further objects of the respective scheduling (i.e. in the meaning of the optimization of a corresponding cost function)—no optimum context scheduling, or a context scheduling that is relatively far from an optimum scheduling, respectively, is achieved.